创作风格指南 v2.0

供 AI 写作时参考。每次创作前必读相关章节。

核心原则（所有文章类型通用）

用最少的字，传递最重的信息，留下最深的印象。

1. 一篇文章只讲一件事。 有且只有一个核心观点。所有内容服务于它，无关的删掉。
2. 前 3 行决定生死。 开头必须命中一个具体的欲望、恐惧或好奇心。不能是背景介绍，不能是废话。
3. 具体胜于抽象。 不写"很多人"，写"三个月前的我"。不写"性能提升"，写"启动时间从 4s 降到 0.8s"。
4. 短句是默认选项。 每句 10-25 字。遇到长句拆开。宁可两句，不要一句说完。
5. 中英文之间加空格。 ROM 程序、SOME/IP 协议，不是 ROM程序。

一、技术文章

1.1 结构模板

# [术语] 是什么，为什么重要，怎么用

## 背景：它解决了什么问题
（用类比解释，让外行也能理解）

## 核心概念
（定义 + 解释 + 图/表格）

## 怎么用 / 怎么配置
（步骤 + 代码 + 参数表）

## 注意事项 / 常见坑
（踩过的坑，直接说）

1.2 写作规则

开头必须有一句话总结（强制）。 紧跟在标题下方，用引用块格式。说"读完能得到什么"，不是"本文介绍了什么"。

❌ 本文介绍了 UDS 诊断协议的基本概念和配置方法。
✅ 读完这篇，你能独立配置 UDS 诊断链路，不用再踩我踩过的坑。

语气： 客观严谨，不用第一人称，不写"我觉得"。
术语： 首次出现给全称。UDS 全称是 Unified Diagnostic Services，即统一诊断服务。之后直接用缩写。
段落： 每段 2-4 行，一段一个概念。段落之间空一行。
代码块： 必须标注语言类型。

# 正确
sign_tool\windows\atb_signer.exe sign --v 2

表格： 3 个以上参数必须用表格，不用列表堆砌。
类比是必选项，不是可选项。 遇到抽象概念，必须给一个类比。

示例：如果没有服务发现，所有节点需要预先配置静态路由——完全退化回 CAN 通信的样子。

标题层级： 最多 3 层（#、##、###），禁止 ####。

1.3 爆款钩子（技术文）

技术文的传播靠"有用"，钩子设计围绕痛点和稀缺信息：

• [X 分钟搞懂] SOME/IP 协议，汽车工程师必看
• 踩了三周的坑，UDS 诊断配置终于跑通了
• 为什么你的 ROM 程序总是启动异常？原因在这里

开头模板（三选一）：

A. 问题式：在 [具体场景] 中，你有没有遇到过 [具体问题]？
B. 结论式：直接说结论。[X] 的本质是 [Y]，不理解这一点，后面全是坑。
C. 对比式：大多数人以为 [常见误解]。实际上，[反常识结论]。

二、工具教程

2.1 结构模板

# [工具名]：[用一句话说能解决什么问题]

## 前置条件
（环境、版本、需要准备什么）

## 步骤
1. [动词开头的短句]
2. ...

## 常见问题
Q：...
A：...

2.2 写作规则

开头必须有一句话总结（强制）。 格式同技术文，引用块，说"读完能做到什么"，不废话。
步骤： 有序列表，每步骤一个动作，动词开头（"打开"、"配置"、"运行"）。
每个步骤配一张截图（写作时标注 [图：xxx] 占位）。
语气： 分享式，像朋友手把手教，不像说明书。
代码块： 必须标注语言，可以直接复制运行。

三、禁止清单（所有类型）

这些写法会直接降低文章质量，遇到就删：

四、排版规范

中英文之间：加空格        → ROM 程序（✅）  ROM程序（❌）
无序列表：用 -            → - 项目一
有序列表：用 1. 2. 3.
嵌套列表：缩进 2 个空格
代码块：必须标语言类型
图片：!650（大图 650，中图 450，小图 250）
强调：使用 **粗体**，一段最多强调 2 处
省略号：。。。（两个句号，非技术文使用）
引用块：重要提示、公式、警告

五、AI 创作时的自检清单

写完一篇文章，按顺序检查：

[ ] 开头是否有一句话总结（引用块格式，说收益不说内容）？
[ ] 开头 3 行是否命中一个具体欲望/恐惧/好奇心？
[ ] 全文是否只有一个核心观点？
[ ] 是否有至少一句可以单独截图传播的金句？
[ ] 所有抽象概念是否都有具体案例或类比？
[ ] 是否有超过 6 行的段落？（有就拆开）
[ ] 技术文：是否有未解释的首次出现术语？
[ ] 排版：中英文之间是否加了空格？